Security is an increasingly important consideration in the design of mobile User Equipment (UE). Prevention of fraud in the operation of the wireless network itself, enabling e-commerce from UE terminals, and the implementation of Digital Rights Management (DRM) to protect content such as audio and video, are a few examples of the compelling need for comprehensive security. This need is being addressed at the core level, as evidenced by the recent TrustZone® extensions to the ARM® processor architecture. TrustZone® is a combination of software and hardware extensions for the ARM® architecture that creates a secure execution environment for trusted code. A TrustZone® enabled CPU operates in one of two virtual processor modes, called worlds. One is the normal world and the other the secure world. These worlds operate independently of each other, and communicate using bank switched registers and caches for rapid context switches between the worlds. A status bit specifies which world is active, and controls access to external resources like Random Access Memory (RAM), Flash storage and peripheral devices.
Even though facilities such as the TrustZone® extensions allow rapid switches between secure and non-secure code execution, such context switches should be minimized for optimal performance. In some situations, switching between secure and non-secure execution environments may be required for every data packet. One example of such a situation is a mobile UE receiving encrypted (i.e., cipher text) data that is protected under a DRM scheme, where the UE passes the data to a separate media player or storage device. A secure CPU process in the UE handles the DRM rights object and content keys. However, a non-secure CPU process must download or stream the data to the external player or storage device, as the communications facilities are non-trusted code. Furthermore, if the data is transferred to the external player or storage device in non-encrypted form (i.e., clear text), the DRM may be thwarted as the content may easily be copied. Thus, the link from the UE to the external device must be secure (encrypted) as well. Where the external player does not support the same encryption scheme, algorithms, or formats as the DRM content owner, directly transferring the received cipher text data is not feasible. Even if the systems are compatible, the DRM may disallow the UE from transferring any content key the external device. Accordingly, the UE must first decrypt the received cipher text data into clear text form using the DRM key, and then re-encrypt the data using a different key for secure transfer to the external device. This is normally done on a per-packet basis, requiring the CPU to constantly switch between secure and non-secure modes.